In-circuit emulators have been used for a number of years by software and hardware developers to help diagnose and debug hardware and software. In-circuit emulation is commonly used to analyze and debug the behavior of complex devices such as microcontrollers and microprocessors that have internal structures too complex to be modeled using simulation software.
A typical arrangement for in-circuit emulation includes a host computer system that is coupled to the microcontroller to be tested through some type of debug logic block. Instructions from the host computer system are loaded to the microcontroller through the debug logic block, which monitors the performance of the microcontroller as the instructions are executed by the microcontroller. As the microcontroller steps through the execution, the debug logic block collects information about the various components of the microcontroller (referred to herein as event information) and feeds that information back to the host computer system. Also, trace information (such as time stamps, register values, data memory content, etc.) may also be logged and fed back to the host computer system.
Thus, a plethora of information is available to the person doing the debugging (e.g., a designer). Oftentimes, an oscilloscope or logic analyzer, coupled to the host computer system or to the debug logic block, is used to present (display) selected event and trace information to the designer. Generally speaking, a logic analyzer is akin to an oscilloscope. Using an oscilloscope or logic analyzer, the designer can view multiple waveforms representing the event and trace information of particular interest.
Sometimes, instead of using an oscilloscope or logic analyzer, the designer reviews the event and trace information recorded by the host computer, and extracts portions of that information that are of interest. The designer can transfer the extracted information to one or more files in a format suitable for graphing software. The graphing software can then plot the data as a waveform that can then be viewed by the designer.
Each of the approaches described above has its disadvantages. The use of oscilloscopes and logic analyzers means that additional equipment must be purchased and maintained, and designers have to be trained in their use. Logic analyzers in particular are relatively expensive pieces of equipment. In addition, it is often difficult and sometimes virtually impossible for a logic analyzer or oscilloscope to have access to points (e.g., registers) and information internal to the device under test (e.g., the microcontroller). For example, the device under test may not be configured to output certain of its internal information to an external device such as an oscilloscope or logic analyzer.
The other approach requires the designer to read and understand the event and trace information, sort out the information that is of interest, and then transfer the information in a suitable format to software that can plot the information as a waveform. The act of filtering out the information of interest is burdensome and prone to error. For example, trace information is generally interspersed with other microcontroller instructions and calls; the designer would therefore have to sort through the entire set of information, separate out the trace information of interest, and arrange it in the proper sequence. Because the event and trace information are typically plotted versus time, the designer also needs to exercise care in selecting instances of event and trace information that will result in proper scaling of the waveform; that is, the shape of the waveform is greatly influenced by the choice of points to be plotted.
Another problem with the latter approach is that essentially the entire event and trace information is collected before the designer can filter out the information that is not of interest. The amount of event and trace information may be substantial and so may consume a significant portion of available memory resources. Conversely, if not enough memory is available, information may be lost.
Therefore, what is needed is a method that can be used for emulating and debugging devices such as microcontrollers, but that does not incur the hardware, maintenance and training costs associated with oscilloscopes and logic analyzers. In addition, what is needed is a method that can satisfy the above need and that can allow access to information that generally is difficult to access or cannot be accessed by conventional logic analyzers and oscilloscopes. What is also needed is a method that can satisfy the above needs but without placing undue burdens on the designer and on available computational (e.g., memory) resources. The present invention provides a novel solution to these needs.